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ABSTRACT 


The Launch Processing System represents Kennedy Space Center's role in providing a major 
integrated hardware and software system for the test, checkout and launch of a new space vehicle. 

Past programs considered the active flight vehicle to ground interfaces as part of the flight systems 
and therefore the related ground system was provided by the Development Center. This paper addresses 
the major steps taken to transform the Launch Processing System from a concept to reality with the 
successful launches of the Shuttle Programs Space Transportation System. 


CONCEPT DEFINITION 


With the baselining of the Space Shuttle Program, NASA was faced with the technical challenge of 
processing and launching a new type of space vehicle. In 1972, a task group was formed at KSC to re- 
view the checkout requirements of the Shuttle elements and to recommend to Shuttle Management a check- 
out system which would satisfy all processing requirements and meet the initial April, 1978 launch 
date. 


Initial system sizing was based on a comparative analysis of analog and discrete measurement and 
stimuli data parameters between Apollo and Shuttle ground and on-board systems (Table I). This 1972 
analysis indicated for initial Shuttle and envelopment flights, the total number of parameters 
(Operational Flight and Development Flight Instrumentation) was approximately the same as Apollo 
ground and on-board systems. 


TABLE I.- COMPARISON BETWEEN APOLLO AND SHUTTLE DATA PARAMETERS IN 1972 


APOLLO 

SHUTTLE (1972) 

ELEMENTS 

PARAMETERS 

ELEMENTS 

PARAMETERS 

SPACECRAFT 

2101 

ORBITER 

OFI 

2300 

DFI 

2800 



PAYLOAD 

230 

— 

LAUNCH VEHICLE 

3188 

SSME SRB ET 

1076 

256 

GROUND SUPPORT 
EQUIPMENT 

4038 

GROUND SUPPORT 
EQUIPMENT 

1787 

— 

TOTAL 

9327 

SUB TOTAL 
TOTAL 

5393 

8449 

3056 


To meet the rapid turnaround time requirement of a reusable vehicle as well as to significantly 
reduce the number of people involved, the entire launch processing activity had to be automated with 
digital computers. It had to be done in such a way to preserve, from a functional point of view, the 
test engineers direct control over checkout and launch procedures. Therefore, a highly functional, 
user-friendly hardware and software interface between the user-engineer and the system was necessary. 
The system had to be modular to handle the various checkout areas which included not only the inte- 
grated vehicle testing and launch, but also the checkout of the individual Shuttle elements; i.e., 
Orbiter, External Tank, and Solid Rocket Boosters. 

Other factors which entered into the review process included such areas as: 

1) Use of existing Apollo Checkout Equipment (ACE) 

2) Use of newly development systems proposed for use during Orbiter manufacturing phase and the 
development and operational phase. Examples of these included Unified Test Equipment (UTE) and a Uni- 
versal Control System (UCS). 
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3) Development of a new Launch Processing System 

4) Phased implementation involving the use of an existing system during the development flight 
period and a new system for the operational phase. 

Based on a thorough examination of all the known factors the decision was made to implement a 
new concept for the automated checkout and launch of the Space Shuttle. 


CONCEPT DEVELOPMENT 


In March, 1973, a civil service team was formed at KSC under the Design Engineering Directorate 
to develop the Launch Processing System (LPS) concept and to provide the systems engineering and inte 
gration required to implement the system. By October, 1973, the "LPS Concept Description Document" 
was released which described an integrated checkout and launch facility capable of controlling the 
Ground Support Equipment (GSE) and Orbiter thru consoles and interfaces using a distributed process- 
ing scheme. The LPS involved two major elements; the Central Data Subsystems (CDS) and the Checkout, 
Control and Monitor Subsystems (CCMS). The Central Data Subsystem (CDS) would provide: 

o Real time data recording and recall 
o Engineering technical file 
o Work authorization and control 
o Pre/post test data analysis 

o Support software and application program library for the LPS checkout system 
o Simulation for software validation and operator training 

The Checkout, Control and Monitor Subsystem (CCMS) involved a modular component, or building 
block, concept which allowed LPS components to be specified at an early date and then configured in 
various ways to accommodate the evolving Shuttle program requirements and the different levels of com 
plexity. Figure 1 depicted the LPS launch support configuration which involved the use of the follow 
ing modular components: 

o Consoles for command and monitor of subsystem functions within an assigned discipline, such 
as LOX, LH2, GN&C, ECS, Payloads 

o Hardware Interface Modules (HIMs) for interfacing with Ground Support Equipment (GSE), such 
as LOX, LH2, Hazardous Gas Detection, Tail Service Masts 

o Front End Processors (FEPs) for receiving data in the LCC and producing a compact computer 
process oriented measurement list and storing the preprocessed data in the CDBFR 

o Common Data Buffer (CDBFR) for providing shared memory for all system data and interconnect- 
ing all distributive processors required to transfer data, commands and computer to computer messages 
o Processed Data Recorder and Stored Peripheral Area (PDR/SPA) where raw/processed data and com 
mands are logged for near real time or post test analysis 

o Timing subsystem, where countdown and real time clock times are generated and controlled 

Other configurations envisioned in the concept document included the following: 

o Maintenance and checkout area 
o ET and SRB "Free Standing" areas 

The Application Programs executed in the consoles would be written in a higher order engineering 
language referred to as GOAL (Ground Oriented Aerospace Language). These programs would provide the 
required test/operations sequencing, command/control, systems monitoring, displays, interlocks as 
defined by the test engineers, and hardware constraints. The programs would be written by the user/ 
operator of the particular subsystem being monitored and controlled by the CCMS. The programs would 
be compiled on the CDS for execution of the subsystem console by the user/operator. The various 
subsystems could be operated in parallel but independently of each other. 

The LPS concept description document was used very successfully by the design team to conduct 
overall concept design review meetings with users at KSC and with MSFC and JSC personnel. In paral- 
lel to these reviews, the design team generated in April, 1974, the LPS Station Set Requirements Docu 
ment which identified all Shuttle Level II programs and other functional requirements levied upon the 
LPS. 


CONCEPT IMPLEMENTATION 


The contractual implementation approach involved the use of four major contracts: (1) System 

Engineering and Software Development; (2) Minicomputers; (3) CCMS Hardware using GFE'd mini- 
computers; and (4) Central Data Subsystem Hardware and Software. The phasing of these contracts is 
shown in Figure 2. 
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Figure 1.- Launch Support Configuration (Circa 1973). 



Figure 2.- LPS Contracts. 


SYSTEM ENGINEERING AND SOFTWARE DEVELOPMENT 

In May, 1974, IBM was selected by NASA to provide the System Engineering and Software Develop- 
ment for the LPS This selection, prior to hardware and computer procurement, allowed a total system 
design to be put in place for the LPS as contrasted to previous programs where the hardware was se- 
lected first and the software was then required to fit a "comm it ted -to" system architectural design. 
Numerous trade studies were conducted by the government/contractor team to determine the allocations 
of processing functions. The results of these studies were tested and simulated to predict the ef- 
fectiveness and performance of each key decision. In parallel to this activity, NASA was performing 
in-house component design and prototyping of key hardware elements. These included such critical 
areas as the Common Data Buffers (CDBFR); man-machine interfaces involving keyboards, color CRT's, 
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programmable function panels, hard copy devices, safing panels; data acquisition, transmission and 
sensors; and distributed computer systems. The CCMS Systems Engineering review and prototype develop 
ment culminated in selection of a distributive minicomputer network architecture which would support 
up to 64 minicomputers or microprocessors to share a common 64K-word, high-speed pipeline memory to 
communicate with each other. These computers perform basically the following functions: 

(1) Man-machine interfaces at a console work station. 

(2; Interface with Ground Support Equipment to insure commands and monitor and limit check 
measurements. 

(3) Interface with the Orbiter on-board computers via the Launch Data Bus 

(4) Interface with the Orbiter command uplink subsystem. 

(5) Record transactions in the 64K shared memory. 

(6) Provide the capability to retrieve, format and print these prerecorded transactions. 


CCMS HARDWARE 

In June, 1975, Modular Computer, Inc. was selected to provide commercial mini -computers (MODCOMP 
11/45) for the operational systems. In August, 1975, Martin Marietta Corp. (MMC) was selected to pro 
vide the design, fabrication, test and installation of the CCMS hardware. By November, 1976 (fifteen 
months later), the initial set of hardware, "Serial-0", was delivered to KSC to support the opera- 
tional software development by IBM. By February, 1977, a subset of CCMS hardware and operating soft- 
ware was made available to the system users/operators to support their application program software 
development using the higher-order language Ground Oriented Aerospace Language (GOAL). Other CCMS 
sets initially implemented included the following locations: 

o Shuttle Avionics Integration Labs at JSC 
o Hypergolic Maintenance Facility at KSC 
o Launch Control Center Firing Rooms 1 & 2 at KSC 
o KSC's Complex Control Center 


CDS HARDWARE AND SOFTWARE 

Proceeding in parallel with the CCMS procurement and delivery activities, the fourth major LPS 
contract was awarded to Honeywell, Inc. for the Central Data Subsystem computers and software sup- 
port. The initial phase of CDS hardware was delivered in early 1976 and installed in the Launch 
Control Center. The basic configuration involved two dual 66/80 Honeywell CPU's sharing a megaword 
of memory. These computers were interfaced to the following primary hardware subsystems: 

o Real-Time Interface (RTIF) used to format CCMS CDBFR data for real time recording on CDS 

o Video Simulation Interface (VSI) used to simulate data into the CCMS in support of CDS 
modeling of ground and on-board systems 

o Communication Processors for interfacing with CCMS consoles and engineering terminals LPS Ap- 
plication Programs 


LPS APPLICATION PROGRAMS 


The development of the software required to automate the processes, control mechanisms and 
testing procedures for checkout and launch of the STS involved the many users of LPS. Each user was 
responsible for creating, modifying and controlling his software, which included the application 
programs, test display skeletons, control logic sequences, and Test Control Supervisor (TCS) sequence 
procedures. The following represents the number of procedures and computer size words used by the 
user for vehicle and ground test: 


User Software 


# Procedures 


Total Word Size 


GOAL Programs 

1381 

Display Skeletons 

563 

Control Logic Sequences 

220 

Test Control Supervisors 

51 


14,230,272 

608,040 

13,170 

56,890 


EVOLVING REQUIREMENTS 


From the time that the initial set of hardware was delivered until the launch of STS-1, numerous 
changes occurred which could have impacted the LPS Operational Readiness Date (ORD) if it had not 
been for the flexibility and modularity of the system hardware and software architecture. Some of 
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the primary changes were: 

o Growth in vehicle and ground support equipment parameters from initial 1972 estimated of 
°14,000 OFI/DFI measurements to 41,000 

o Bulk Memory addition to the consoles 

o TCS Compiler/Loader (GOAL On , Board IF) 

o Safing & Biomedical System 

o Monitor Consoles in support Firing Room 

o Huntsville Operating Support Center (HOSC) Interface to MSFC 

o FEP Expansion to handle PCM/GPC formats 

o Orbiter Computational Facility for processing Mass Memory Load Tapes 
o Processing of Non-Standard Data Types 
o Real Time Diagnostics 

The Firing Room LPS configuration which supported the launch of STS-1 consisted of 41 minicom- 
puters and 4 microprocessors actively communicating through the Common Data Buffer. An additional 8 
CPU's in FR2 were actively connected to the same CDBFR in a data monitoring, engineering support 
role. The 1973 LPS concept depicted in Figure 1 had become a reality. 


REALITY 


The Launch Processing System successfully supported the checkout and launch of the first reus- 
able Space Transportation System in April, 1981. Since this was the first launch, the NASA/IBM 
engineering team performed post processing analysis of the data processed by the CCMS FR #1 computers 
during terminal countdown to evaluate system performance. Areas measured included the following: 

o Processed Data Recorders (PDR) FIFO/Logging activity as a measure of computer comnunication 
activity across/through the Common Data Buffer (CDBFR). (Excessive logging could result in loss of 
recorded data) 

o Computer-to-computer (C-C) activity 

The PDR FIFO/Logging rate to disk and tape for STS-1 experienced 31K-word pairs in one second 
during the terminal count against a design limit of 33K-word pair per second. Prior to STS-2, CCMS 
S/W modifications were incorporated which raised the loss-of-data rate to 58K-word pairs of logging. 
Figure 3 provides the highest logging rates and the tape switchover rate for STS-1 thru STS-6. 

The maximum number of computer-to-computer (C-C) transactions per second which the CCMS could 
handle across the CDBFR was determined prior to STS-1 to be 670. This number represented the maximum 
system load before loss of logged data occurs. Figure 4 depicts the maximum C-C's per second 
encountered during STS-1, 2, 3, and 6 terminal counts. 
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Figure 3.- PDR Logging Rates (Maximum) During STS Terminal Count. 


Since the launch of STS-1, a significant number of changes have been incorporated in LPS due to 
vehicle and/or ground changes. Examples of these are listed below. The changes were implemented 
without impacting the system architecture which again demonstrated the flexibility and modularity of 
the hardware and software elements. 

o Console Memory Margins Requiring GOAL Rewrite 
o DOD Payload Security 
o Launch Data Bus FEP 
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STUDY LIMIT 

Figure 4.- Maximum C-to-C In a Second During STS Terminal Count. 


o Application Program Growth Affect Disk Sizing 
o Payload FEP addition 
o Data Bank Restructure 

o Engineering Support Assembly Data Display Rates 
o Format changes affecting FEP memory sizing 


OPERATIONAL ASSESSMENT 


In January, 1981, KSC initiated a 9-month study which addressed the required performance of all 
LPS elements during the Shuttle operational era. An indepth analysis of all off-line and on-line LPS 
processes required to support vehicle testing, checkout, launch and landing was conducted. Signifi- 
cant recommendations which are resulting in system changes today are as follows: 

o Restructure Data Bank to make it less sensitive to vehicle changes or mission-to-mission 
changes 

o Restructure Test Configured Identification (TCID) Build and Load processes to allow easier 
changes and on-line mods 

o Enhance software build processes to improve quality and documentation of outputs 
o Add equipment which allows Firing Room Sets to be split to perform multiple tasks 
o Add capability to conduct STS element (off-line) tests from the Software Production Facility 
(FR2) to off-load FR1 & 3 integrated tests and launch activities 

o Enhance O&M functions to reduce system down-time and reconf iguration times 

As the Space Transportation System moves into its operational phase, KSC has reviewed the LPS 
for any potential hardware areas which could affect system performance. This review has included 
available memory margins, maintainability/spares availability, etc. Two areas are currently under 
review; the first, memory margins in the console minicomputers and second, the repair problems asso- 
ciated with the console 128K extended bulk memory. The console CPU main memory is limited by design 
to only 64K words with only 100 unused words (<1%). One major software upgrade to the GOAL exec- 
utive has been performed which yielded 1300 additional locations. Subsequent changes have reduced 
the margin to the current figure and another software modification to reclaim additional memory is 
not advised. To offset the potential risk of exceeding current CPU capacity, KSC has developed an 
emulator (with up to 2M words of executable main memory) which can replace a Modcomp 11/45 and its 
associated bulk memory in any console configuration and support all required functions without 
requiring all CPU's in a particular set to be upgraded at the same time. With the availability of 
this capability in October, 1984, the Launch Processing System will be capable of supporting the 
Space Transportation System well into the 1990 's. 


OPERATIONAL SYSTEMS 


Today, twelve LPS systems are operational with two additional planned for the future. The sets 
are located not only at KSC but also on the Eastern Test Range (ETR) in support of DOD payload pro- 
cessing, at JSC in support of Orbiter avionics to ground interface testing, and at Vandenberg Air 
Force Base in support of Shuttle and DOD payload testing, checkout and launch from the West Coast. 
Capabilities are being added which allow data communcation between individual CCMS sets, such as a 
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VAFB set and a KSC Firing Room set. The CCMS sets have been optimized for the functions which they 
are required to support. The distributive minicomputers and microprocessors connected to a CDBFR 
vary from two in the Air Force's Orbiter Functional Simulator to as many as forty-five in a full-up 
Firing Room. The operational software is modular and can support all CCMS sets without requiring in 
dividual releases. 


SUMMARY 


Through the dedicated and competent efforts of a NASA civil service and contractor team, the 
Launch Processing System has been brought from concept to operational support. The Launch Processing 
System is a very integral and key element of the Space Transportation System. LPS is supporting the 
Shuttle processing very successfully and shall continue in its support role as processing timelines 
are reduced to achieve the Shuttle Operational Era goals. It's demonstrated flexibility and modular- 
ity will allow it to continue to be adapted to unforeseen and changing program requirements. As we 
move toward the future, the distributive computer architecture employed in LPS will serve as a corner- 
stone for evaluating other systems as they are conceived and become a reality. 
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